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EXECUTIVE  SUMMARY 

The  Force  Protection  Experiment  III  (FPE  III)  was  an  experimental  exercise  conducted  at  the 
Mounted  Warfare  Test  Bed  (MWTB)  at  Fort  Knox,  KY  from  October  28  to  December  5, 
1996.  The  experiment  was  performed  as  Delivery  Order  (DO)  #0019  under  the  Lockheed 
Martin  Advanced  Distributed  Simulation  Technology  II  (ADST II)  Contract  administered  by 
the  U.S.  Army  Simulation,  Training,  and  Instrumentation  Command  (STRICOM).  The 
experiment  was  sponsored  by  three  Government  agencies:  Program  Manager,  Combat 
Identification;  Tank  Automotive  &  Armaments  Command  (TACOM)  Research, 
Development,  &  Engineering  Center  (TARDEC);  and  the  Mounted  Maneuver  Battle  Lab 
(MMBL),  Fort  Knox,  KY.  The  experiment  utilized  a  synthetic  environment  that  employed 
virtual  simulations  to  depict  an  Armor  Company  executing  four  basic  company-level 
scenarios  in  realistic  combat  situations  in  various  experimental  configurations.  The 
scenarios  were  developed  to  be  run  on  the  Fort  Hood  terrain  database,  and  included  Attack, 
Defend  and  Movement  to  Contact  vignettes.  These  scenarios  were  designed  to  produce 
survivability  events,  provide  fratricide  risk,  and  induce  the  commanders  to  make  tactical 
decisions  which  affected  battle  outcomes.  The  objectives  of  the  effort  were: 

1)  To  investigate  the  effects  on  mission  performance  at  Platoon  and  Company  levels 
of  various  combinations  of  a  digital  command  and  control  system,  a  friendly  vehicle 
identification  system,  a  vehicle  hit  avoidance  system,  and  a  supplemental  digital  situational 
awareness  system. 

2)  To  investigate  the  effects  of  an  interrogation  and  response  combat  identification 
system  on  fratricide  occurrence  and  gunnery  performance. 

3)  To  investigate  the  effects  of  a  supplemental  digital  communication  system  on  the 
timeliness  and  accuracy  of  a  digitized  local  battlefield  information  and  Single  Channel 
Ground  and  Airborne  Radio  System  (SINCGARS)  net  loading. 

4)  To  investigate  the  effects  on  vehicle  survivability  of  hit  avoidance  sensors  and 
countermeasures  within  the  armor  Platoon. 

5)  To  investigate  the  effects  on  vehicle  survivability  of  passing  hit  avoidance 
information  locally  using  a  supplemental  digital  communication  system. 

6)  To  identify  combat  identification  modeling  parameters  for  input  to  constructive 
combat  models. 

7)  To  investigate  the  requirement  for  new  or  modified  tactics,  techniques,  and 
procedures  introduced  by  Enhanced  Battlefield  Combat  Identification  System  (E-BCIS)  and 
the  Integrated  Defense  System  (IDS). 

Development  of  the  software  modifications  to  Modular  Semi-Automated  Forces  (ModSAF) 
and  the  initial  integration  of  software  models  was  conducted  at  the  Operational  Support 
Facility(OSF)  in  Orlando,  FL  from  July  15  to  August  20, 1996.  The  final  integration  phase 
was  completed  at  the  MWTB  from  September  3  to  27, 1996.  Additionally,  the  E-BCIS 
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model  development  was  performed  by  MITRE  in  Bedford,  MA  and  the  IDS  model 
development  was  performed  by  Optimetrics,  Inc  (OMI)  in  Ann  Arbor,  MI. 

In  accordance  with  the  Government  Statement  of  Work,  the  experiment’s  test  trial  window 
was  six  (6)  weeks.  This  six  week  period  included  five  weeks  to  execute  the  trial  run  matrix 
and  an  additional  week  scheduled  for  make-up  of  non- validated  runs,  if  required.  The 
experiment  baseline  case  was  comprised  of  a  non-digital  (radio  voice  only)  Command  and 
Control  System.  Subsequently,  additional  systems  (Applique,  IDS,  and  E-BCIS)  were 
separately  added  and/or  combined  with  the  baseline  case  in  an  effort  to  detect  the 
incremental  contribution  of  each  system. 

The  entire  trial  run  matrix  was  executed  within  the  allocated  five  weeks  with  no  additional 
time  required  for  make-up  of  non-validated  runs.  As  a  result,  the  sixth  week  was  made 
available  for  E-BCIS  only  excursion  runs  and  a  demonstration  of  the  final  virtual  simulation 
version  of  the  IDS.  The  activities  of  this  week  had  no  impact  on  analysis  of  runs  in  the 
matrix  or  on  schedule. 

In  accordance  with  the  Government  SOW,  this  Final  Report  includes  a  description  of  the 
experiment,  its  conditions  and  conduct,  and  lessons  learned.  This  report  addresses  the 
interconnectivity  of  simulation  systems,  modifications  to  both  ModSAF  and  the  manned 
simulators,  and  the  integration  of  Government  Furnished  software  models.  This  report  does 
not  include  discussion  of  data  analysis  nor  conclusions  as  to  whether  the  customer(s) 
achieved  their  objectives  of  the  experiment. 
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1.  INTRODUCTION 

1.1  Purpose 

The  purpose  of  this  final  report  is  to  document  the  ADST II  effort  which  supported  FPE  III. 
This  report  includes  a  full  description  of  the  experiment,  its  conditions,  and  lessons  learned. 
A  more  detailed  “blueprint”  of  the  FPE  III  system’s  architectural  design  is  found  in  the 
separately  prepared  document  entitled  the  “Hardware  Design  and  Configuration  Document.” 
(HDCD)  (CDRL  AB03). 

1.2  Contract  Overview 

FPE  III  was  performed  as  DO  #0019  under  the  Lockheed  Martin  Corporation  (LMC)  ADST 
II  contract  with  STRICOM.  The  contract  required  LMC  to  perform  a  Mini-Feasibility 
Analysis  Study  (Mini-FAS)  to  determine  the  best  technical  approach  for  providing  a 
Command  and  Control  Tactical  Display  (C2TD)  system  for  use  in  the  experiment,  and  to 
determine  the  best  technical  approach  for  integrating  the  IDS  and  E-BCIS  with  the  C2TD. 
The  Mini-FAS  was  successfully  completed  in  the  month  of  June.  At  the  conclusion  of  the 
Mini-FAS,  STRICOM  and  LMC  conducted  a  customer  decision  brief  on  July  2, 1996.  The 
purpose  of  this  decision  briefing  was  to  obtain  customer  approval  of  the  Mini-FAS  findings 
and  recommendations,  permission  to  revise  the  proposal,  and  permission  to  proceed  with  the 
proposed  experiment  timeline.  A  detailed  description  of  the  activities  and  findings  of  the 
Mini-FAS  are  documented  in  the  initial  Mini-FAS  Report  (CDRL  ABOl)  submitted  July  30, 
1996  and  the  final  version  dated  October  18, 1996. 

1.3  Experiment  Overview. 

The  purpose  of  FPE  III  was  to  use  man-in-the  loop  simulators  and  simulated  forces  to 
evaluate  the  effect  of  combining  vehicle  survivability,  combat  identification,  and  digital 
communication  systems  on  ground  combat  vehicles  operating  as  a  Company  element  of  a 
Battalion  Level  Combined  Arms  Task  Force.  Data  was  collected  to  capture  soldier  responses 
to  survivability  events  and  the  command  and  battle  staffs  ability  to  use  the  additional 
experimental  digital  information  to  improve  their  battlefield  performance.  The  experiment 
was  designed  to  provide  the  Government  with  the  opportunity  to  review  and  revise: 
operational  effectiveness;  tactics,  techniques,  and  procedures  (TTPs);  soldier-machine 
interfaces;  training;  and  input  parameters  for  constructive  modeling.  The  experiment 
employed  four  manned  Ml  A2  simulators  (configured  as  Ml  A1  variants)  as  a  Platoon  within 
a  Blue  Armor  Company.  The  remainder  of  the  Company  was  rounded-out  with  two 
additional  tank  platoons  of  Blue  ModSAF;  two  ModSAF  Bradley  Fighting  Vehicles  as 
Scouts;  and  a  Company  Commander  and  Executive  Officer  role-playing  from  a  ModSAF 
workstation.  The  Blue  Force  (BLUEFOR)  conducted  tactical  operations  against  a  doctrinally 
approved  and  depicted  Opposing  Force  (OPFOR)  ModSAF  threat. 
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1.4  Technical  Overview 

The  technical  approach  to  the  Force  Protection  III  Experiment  involved  the  conduct  of  the 
Mini-FAS,  integrating  the  Applique  C2TD  selected  by  the  Mini-FAS,  integrating  the  IDS 
and  E-BCIS  with  the  selected  C2TD  system,  modification  to  ModSAF  version  2.1,  and 
modification  of  the  Precision  Lightweight  Global  Positioning  System  (GPS)  Receiver 
(PLGR).  Details  on  the  modifications  to  ModSAF  and  PLGR  are  documented  in  the 
Version  Description  Documents  (VDDs),  (CDRL  AB04).  The  following  is  a  short  synopsis 
of  the  technical  integration  effort  for  the  experiment. 

ModSAF  development  and  initial  integration  of  software  model  changes  were  conducted  at 
the  Operational  Support  Facility  (OSF)  during  the  test  and  development  portion  of 
integration.  This  initial  work  effort  was  shipped  and  reinstalled  at  the  MWTB  and 
subsequently  completed  during  the  four  week  on-site  integration  period.  Once  the  synthetic 
environment  functional  tests  were  completed.  Fort  Knox  conducted  troop  training  and  a  Pilot 
Test.  After  the  Pilot  Test,  a  week  was  used  to  make  final  fixes  and  provided  additional  time 
for  troop  training.  The  Test  Readiness  Review  (TRR)  was  held  on  October  24,  1996  to 
freeze  the  experiment  configuration  and  receive  approval  to  start  the  experiment,  which 
began  on  October  28, 1996.  The  actual  experiment  period  lasted  five  weeks  during  which  96 
different  iterations  were  executed  using  four  basic  scenarios.  A  sixth  week,  which  was 
available  for  conduct  of  make-up  experiment  trials,  was  not  required.  This  sixth  week  was 
therefore  made  available  for  E-BCIS  only  excursion  runs  and  a  demonstration  of  the  final 
virtual  simulation  version  of  the  IDS. 


2.  Applicable  Documents 

2.1  Government 

-ADST II  Work  Statement  for  Force  Protection  Experiment  III  (FPE  III),  May  24, 
1996,  AMSTI-96-W039,  Version  2.0 

-ADST  II  Work  Statement  for  Force  Protection  Experiment  III  (FPE  III),  July  30, 
1996,  AMSTI-96-W039,  Version  3.0 

-Battle  Lab  Experiment  Plan  (BLEP)  for  Force  Protection  Experiment  III  (FPE  III), 
ATZK-MW,  Fort  Knox,  KY,  April  24, 1996 

-Battle  Lab  Experiment  Plan  (BLEP)  for  Force  Protection  Experiment  III  (FPE  III), 
ATZK-MW,  Fort  Knox,  KY,  August  15, 1996 

2.2  Non-Government 

-ADST  II  Technical  Approach  for  Force  Protection  Experiment  III  (FPE  III), 

April  30, 1996,  ADST  II-TAPP-018R-9600048B 

-ADST  II ECP  Technical  Approach  for  Force  Protection  Experiment  III  (FPE  III), 
July  24, 1996,  ADST  II-TAPP-018R-9600228 
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-ADST II  CDRL  ABOl,  Force  Protection  Experiment  III  (FPE  III)  Mini-FAS  Report, 
July  30, 1996,  ADST-II-CDRL-018R-9600223 

-ADST  II  CDRL  ABOl,  Force  Protection  Experiment  III  (FPE  III)  Mini-FAS  Report, 
October  18,  1996,  ADST-II-CDRL-018R-9600223A 

-ADST  II  CDRL  AB04,  Force  Protection  Experiment  III  (FPE  III)  Cold  Start  Manual, 
ADST-II-CDRL-0 1 8R-9600424 

-  ADST  II  CDRL  AB04,  Force  Protection  Experiment  III  (FPE  III)  VDD-ModSAF, 
ADST-II-CDRL-0 1 8R-9600425 

-  ADST  II  CDRL  AB04,  Force  Protection  Experiment  III  (FPE  III)  VDD-PLGR, 
ADST-II-CDRL-0 18R-9600437 

-  ADST  II  CDRL  AB04,  Force  Protection  Experiment  III  (FPE  III)  VDD-  Applique, 
Interface,  ADST-II-CDRL-0 1 8R-960043  8 

-  ADST  II  CDRL  AB04,  Force  Protection  Experiment  III  (FPE  III)  VDD-IDS  Tones, 
ADST-II-CDRL-0 1 8R-9600439 

-  ADST  II  CDRL  AB04,  Force  Protection  Experiment  III  (FPE  III)  VDD-Ml  A2, 
ADST-II-CDRL-01 8R-9600478 

-ADST  II  CDRL  AB04,  Force  Protection  Experiment  III  (FPE  III)  Hardware  Design 
and  Configuration  Document,  ADST-II-CDRL-0 18R-9600426 

-ADST  II,  Force  Protection  Experiment  III  (FPE  III)  Design  Review  SEIT,  August 
23, 1996,  ADST-II-SEIT-018R-9600449 

-ADST  II,  Force  Protection  Experiment  III  (FPE  III),  Post  DO  SEIT,  December  19, 
1996,  ADST-II-SEIT-018R-9600450 


3.  System  Description 

3,1  System  Configuration  and  Layout 

The  Mounted  Warfare  Test  Bed  at  Fort  Knox,  KY,  contains  a  variety  of  vehicle  simulators, 
networks,  Semi-Automated  Forces  (SAF)  capabilities,  displays  for  monitoring  the  battlefield, 
utilities  to  facilitate  exercises,  automated  data  collection  capabilities,  and  data  reduction  and 
analysis  subsystems.  The  MWTB  simulation  and  support  platforms  used  for  FPE  III  are 
depicted  in  Figure  1. 
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FPE  III  Asset  Layout  at  MWTB 
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Figure  1  FPE  III  Asset  Layout  at  MWTB 

The  experiment  was  conducted  using  assets  interconnected  on  Ethernet  LANs  via  thin  net 
cable.  Simulation  assets  used  Distributed  Interactive  Simulation  (DIS)  2.03  protocol.  Table 
1  lists  assets  used  at  the  MWTB. 


ADST  II  ASSET 

PURPOSE 

PROTOCOL 

Modified  M1A2  Simulator 

Ml  A1  Simulator  for  Manned  Tank  Platoon 

DIS 

Stealth 

Battlefield  Display  for  Company 

Commander  Role-player 

DIS 

ModSAF  Workstations 

Semi-Automated  Forces  for  OPFOR,  two 
BLUFOR  Ml  Platoons,  &  Scout  Section 

DIS 

SINCGARS  Face  Plates 

Simulated  Radio  Communications 

DIS 

Plan  View  Display 

Terrain  Map  of  the  battlefield  for  Exercise 
Control 

DIS 

Data  Loggers 

Record  of  DIS  PDUs  for  Data  Collection  & 
Analysis 

DIS 

DIS  Time  Stamper 

Time  Stamp  of  DIS  PDUs  for  Data 

Collection  &  Analysis 

DIS 

Table  1  ADST II  MWTB  Assets 
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In  addition  to  the  manned  simulators  and  assets  listed  in  Table  1  above,  there  were  seven 
SGIs,  two  Sun  workstations,  twenty  two  full  size  PCs,  and  four  portable  PCs  required  to 
support  the  experiment.  Figure  2  depicts  the  FPE  III  Hardware  and  Interface  Diagram  to 
support  the  experiment. 


FPE  ni  Hardware  and  Interface  Diagram 
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Figure  2  FPE  III  Hardware  and  Interface  Diagram 


3.2  Description  of  System  Components 

This  section  discusses  the  description,  functionality  and  operation  of  the  system  components, 
which  includes  the  GFE  models  and  their  integration  with  the  hardware  at  the  MWTB. 
Additional  technical  information,  such  as  a  more  detailed  technical  description,  specific 
hardware  configuration  characteristics,  basic  operating  instructions,  and  drawings  are 
provided  separately  in  the  HDCD. 

3.2.1  Applique 

The  Applique  Command  and  Control  Tactical  Display  software  was  developed  by  TRW  of 
Carson,  CA  and  provided  by  the  Program  Manager  Applique.  FPE  III  used  Applique  version 
1.01a  which  was  the  latest  and  most  mature  of  seven  versions  developed  at  the  conclusion  of 
the  Mini-FAS.  Subsequent  versions  were  developed  during  the  execution  of  this  experiment. 
The  Applique  computer  display  was  mounted  to  the  left  of  the  Tank  Commander  in  the 
manned  simulator.  It  provided  the  Commander  with  a  color  map  showing  accurate,  timely 
Platoon  member  locations,  threat  warnings,  and  map  overlays.  Applique  allowed  the 
Commander  to  send  and  receive  Intelligence  Reports,  Contact  Reports,  and  Fragmentary 
Orders. 
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3.2.2  Tactical  Internet  Model  (TIM) 

The  Tactical  Internet  Model  (TIM)  was  provided  by  MITRE  Corporation  and  the 
Communications  and  Electronics  Command  (CECOM).  The  TIM  helped  to  provided  a 
simulation  of  realistic  voice  and  data  radio  communications.  The  TIM  includes  a  simulation 
of  the  Internet  Controller  (INC)  which  serves  as  a  router  for  the  exchange  of  data  messages 
within  the  Tactical  Internet.  Additionally,  a  separate  PC  hosted  the  TIM  Utilities  Operations, 
which  provided  automated  initialization  and  maintenance  functions.  This  same  PC  also 
functioned  as  the  TIM  Propagation  Server,  which  provided  terrain  propagation  calculations  to 
each  of  the  individual  TIM  PCs  for  use  in  creating  realistic  communication  delays  and 
corruption  due  to  terrain  and  distance. 

3.2.3  Precision  Lightweight  Global  Positioning  System  Receiver  (PLGR)  Model 
Operations 

The  Government  SOW  required  a  simulated  position  location  system  software  model  be 
used  to  provide  current  location  of  host  platforms.  The  system  would  provide  a  position  with 
statistically  induced  errors  as  would  be  measured  by  a  realistic  GPS  system.  With  the 
Applique  system  it  was  anticipated  that  the  Experimental  Force  (EXFOR)  Applique  PLGR  or 
an  alternate  PLGR  simulation  would  be  used. 

As  a  result  of  the  Mini-FAS  and  with  the  selection  of  Applique,  the  EXFOR  PLGR  model 
was  modified  to  work  with  Applique  version  1.01a.  This  model  was  used  in  the  Functional 
Test  and  modified  after  the  Pilot  Test  to  fix  some  anomalies  that  appeared.  Although  the 
PLGR  model  was  operational  prior  to  the  start  of  the  experiment,  there  was  and  still  is  a 
PLGR/ Applique  1.01a  communication  problem  which  causes  occasional  communications 
lock-ups.  Due  to  the  complexity  of  the  experiment,  the  integration  and  involvement  of 
numerous  software  models,  the  lengthy  start  up  time  required  to  bring  up  all  subcomponents 
prior  to  the  start  of  a  trial  nm,  and  the  ability  of  the  Applique  LAN  interface  to  provide 
instant  and  accurate  position  location,  the  PLGR  model  was  not  used. 

The  decision  to  remove  the  PLGR  from  the  experiment  and  use  the  Applique  LAN  interface 
for  this  functionality  instead  was  recommended  and  approved  by  all  the  customers  at  the  Test 
Readiness  Review.  This  decision  provided  a  savings  of  over  one  hour  per  day  in  start  up 
time,  which  in  turn  provided  more  simulator  run  time  for  the  actual  experiment.  The  issue  of 
Applique  providing  perfect  location  in  lieu  of  the  normal  GPS  induced  error  was  overcome 
by  the  fact  that  the  induced  error  for  the  Fort  Hood  database  was  1 0-30  feet,  and  the  fact  that 
the  entity  icon  on  the  Applique  screen  was  equivalent  to  200  meters  in  size.  Therefore,  the 
error  was  transparent  to  the  troops  and  the  experiment.  Additionally,  it  was  noted  that  the 
error  induced  by  using  single  precision  float  format  for  the  new  PLGR  position  messages 
also  included  a  10-30  foot  error. 

3.2.4  E-BCIS  Model  Operations 

The  E-BCIS  was  provided  by  MITRE  Corporation,  Bedford,  MA  through  PM  Combat  ID. 
This  system  provided  situational  awareness  for  the  crew  and  adjacent  members  of  the  Platoon 
and  Company.  This  situational  awareness  was  provided  by  both  information  gathering  and  a 
friendly  position  location  reporting  function.  Information  gathering  was  provided  by  an 
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interrogation  and  response  function  wherein  either  the  Gunner  or  Tank  Commander  could 
initiate  a  query  by  lasing  on  a  target.  Initiation  of  a  lase  would  simultaneously  initiate  a 
directional  millimeter-wave  (MMW)  signal  broadcast  (a  query),  which  would  be  picked  up 
by  other  friendly  vehicles  in  the  signal’s  path.  Friendly  vehicles  receiving  the  query  would  in 
turn  respond  with  an  omni-directional  MMW  signal  indicating  their  identity.  The  result  of 
the  query  would  be  a  ’’Friend,”  Friend-in-Sector,”  or  an  ’’Unknown”  response.  This  response 
was  provided  to  the  crew  via  a  tone  through  the  crew  headsets,  an  icon  displayed  on  the 
Applique  tactical  display,  and  lights  in  both  the  Commander’s  and  Gunner’s  sights.  In 
addition  to  the  manned  simulators,  E-BCIS  was  also  configured  to  obtain  responses  from 
Blue  ModSAF  vehicles. 

E-BCIS  also  provides  an  automatic  position  reporting  capability  via  a  digital  data  link 
(DDL).  With  DDL,  each  E-BCIS  equipped  vehicle  sends  out  a  periodic  (heart  beat)  MMW 
signal  containing  the  vehicle’s  current  GPS  position.  Every  other  E-BCIS  equipped  vehicle 
within  a  1  Km  range  receives  this  data  and  records  it  in  its  own  situational  awareness  data 
base.  These  locations  are  then  displayed  on  the  Applique  screen. 

3.2.5  IDS  Operations 

The  IDS  was  provided  by  Optimetrics,  Inc,  Ann  Arbor,  MI  through  TARDEC.  This  system 
operated  within  the  simulator  and  provided  early  warning  and  detection  of  threat  munitions 
directed  toward  the  vehicle.  After  detection  and  warning  were  completed,  a  countermeasure 
device  was  employed  to  protect  the  vehicle  against  the  threat.  IDS  was  configured  with  a 
Missile  Warning  Receiver,  Missile  Countermeasure  Device,  and  smoke.  The  IDS  worked  in 
the  “automatic  mode”  only  ( automatic  detection,  classification,  and  release  of 
countermeasures) . 

The  detection  and  warnings  were  provided  to  the  crew  by  tones  and  voice,  and  followed  by  a 
visual  display  on  the  Applique  screen.  The  displays  on  the  Applique  screen  occurred  at  the 
next  screen  update,  which  ran  on  a  twenty  second  update  cycle. 

3.2.6  Applique  LAN  Interface 

In  addition  to  being  connected  to  simulated  TIM  radios  via  the  INC,  each  Applique  was 
intercormected  via  an  Applique  LAN.  An  Applique  LAN  Interface  workstation  provided  a 
communications  bridge  between  the  Applique  and  DIS  LANs.  This  facilitated  the  passing  of 
certain  ModSAF  entity  locations,  E-BCIS  data,  and  IDS  data  over  the  DIS  network  to  the 
Appliques.  The  Applique  LAN  Interface  converted  the  necessary  data  from  DIS  PDUs  into 
Variable  Message  Format  (VMF)  messages  in  User  Data  Protocol  (UDP)  packets  for 
communication  to  the  Appliques.  The  Applique  LAN  was  only  used  to  receive  VMF 
messages  from  the  Applique  LAN  Interface  and  not  for  communications  from  one  Applique 
to  another.  This  level  of  communication  was  performed  via  the  TIM/INC  radio  emulator  for 
realistic  communications  within  the  synthetic  environment. 

3.2.7  Manned  Simulators 

Four  Ml  A2  simulators  were  used  for  FPE  III.  The  simulators  represented  a  Tank  Platoon  as 
part  of  an  Armor  Company.  Each  simulator  was  modified  to  replicate  the  Ml  A1  variant  with 
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E-BCIS,  and  had  an  Applique  Command  and  Control  Tactical  Display  (C2TD)  installed. 

The  C2TD  was  a  Compaq  Elite  Laptop  Computer  purchased  for  the  experiment.  The 
computer  is  running  with  the  Santa  Cruz  Operating  System  (SCO)  UNIX  and  Applique 
software  version  1.01a. 

3.2.8  ModSAF  Operations 

ModSAF  version  2.1  was  used  for  FPE  III.  ModSAF  was  used  for  BLUFOR  round-out  and 
OPFOR.  BLUFOR  ModSAF  provided  the  two  additional  platoons  required  to  round-out  the 
Armor  Company,  plus  the  Company  Commander  and  Executive  Officer,  and  a  Scout  Section. 
OPFOR  were  provided  in  a  configuration  of  a  Motorized  Rifle  Battalion  to  complete  the 
scenario  requirements. 

3.2.8.1  ModSAF  Enhancements 

ModSAF  was  enhanced/modified  for  FPE  III  to  meet  specific  requirements.  A  library  “Lib 
Applique”  was  added  to  send  data  PDUs  to  the  Applique  interface.  These  data  PDUs  were 
used  to  provide  the  ModSAF  entities  positions  to  the  Applique  systems.  Additionally,  new 
munitions  with  associated  damage  tables  (Sagger,  Songster,  Spandrel,  and  Spiral)  were  added 
to  support  IDS.  The  ModSAF  VDD  (CDRL  AB04)  discusses  this  in  detail.  Subsequent 
modifications  have  been  made  that  include  this  functionality  in  the  LAN  interface  for  future 
applications  in  order  to  use  standard  versions  of  ModSAF. 

3.2.9  Data  Logger 

The  Data  Logger  is  an  ADST II  asset  that  captures  the  network  traffic  and  places  the  data 
packets  on  a  disk  or  tape  file.  The  Data  Logger  performs  the  following  functions: 

a.  Packet  Recording  -  Receives  packets  from  the  DIS  network,  time  stamps  and  then 
writes  to  a  disk  or  tape. 

b.  Packet  Playback  -  Packets  from  a  recorded  exercise  can  be  transmitted  in  real  time  or 
faster  than  real  time.  The  Data  Logger  can  also  suspend  playback  (freeze  time)  and 
skip  backward  or  forward  to  a  designated  point  in  time.  The  logger  can  be  controlled 
directly  from  the  keyboard  or  remotely  from  the  Plan  View  Display  (PVD).  Playback 
is  visible  to  any  device  on  the  network  (PVD,  Stealth  Vehicle,  a  vehicle  simulator, 
etc.). 

c.  Copying  or  Converting  -  Files  are  copied  to  another  file,  which  can  be  on  the  same  or 
a  different  medium;  and  files  from  the  older  version  of  the  Data  Logger  can  be 
converted  to  a  format  compatible  with  the  current  version  of  the  Data  Logger. 

For  FPE  III,  two  data  loggers  were  employed  to  capture  the  exercise.  The  two  data  loggers 
were  placed  on  the  DIS  net  to  capture  all  DIS  PDUs  for  analysis.  These  two  loggers  used 
Sun  IPX  systems  with  48  MB  RAM,  1  GB  Hard  drive,  utilizing  the  Sun  OS  4.1.3  operating 
system.  One  data  logger  was  designated  as  a  back  up  and  was  not  needed. 
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3.2.9.1  AudioA^ideo  Capture 

Fort  Knox  Television  installed  video  and  audio  monitors  to  capture  video  from  the  sights  and 
audio  from  the  intercom  systems  in  each  manned  simulator.  Visual  and  audio  data  was 
recorded  through  the  sights  and  intercom  systems  on  every  trial  run  for  data  collection.  The 
data  was  reduced  by  the  Research  Assistants,  plugged  into  the  data  logger  for  a  time  line,  and 
then  turned  over  to  the  representative  from  Test  and  Evaluation  Command  Coordination 
Office  (TECO)  for  further  analysis.  Although,  data  analysis  is  not  part  of  this  report,  the 
process  is  discussed  in  more  detail  in  paragraph  4.3. 

3.2.10  Time  Stamper 

The  MWTB  provided  a  Time  Stamper  which  consisted  of  a  video  time  code  generator.  This 
time  code  generator  produced  time  data  in  days,  and  since  1  January,  in  hour/min/sec  format. 
It  also  ran  on  an  IBM-compatible  Personal  Computer  (PC).  The  PC  was  programmed  to  read 
the  video  time  code,  convert  the  time  data,  and  then  generate  a  Time  PDU  which  was  then 
issued  on  the  DIS  network  each  second.  This  provided  the  real  world  clock  time  on  the 
logged  data  to  assist  in  subsequent  analyses.  This  time  was  also  used  by  PLGR  to  maintain 
their  time. 

3.2.11  Stealth  System 

The  ADST II  Stealth  gives  the  Observer/Controller  (0/C)  personnel  a  “window”  into  the 
virtual  battlefield  allowing  them  to  make  covert  observations  of  the  action  occurring  during 
the  scenario.  In  addition,  through  the  use  of  the  data  logger,  the  Stealth  gives  observers  and 
analysts  an  After  Action  Review(AAR)  capability.  The  Stealth  is  a  visual  display  platform 
that  consists  of  a  Plain  View  Display  (PVD),  various  input  devices,  and  three  video  displays 
that  provide  the  operator  with  a  panoramic,  3D  view  of  the  battlefield. 

The  Stealth  permits  the  controller  to  fly  around  the  virtual  battlefield  and  view  the  simulation 
without  interfering  with  the  action.  The  features  of  the  Stealth  allow  the  observer  to  survey 
the  virtual  battlefield  from  a  variety  of  different  perspectives,  including: 

a.  Tethered  View  -  Allows  the  user  to  attach  unnoticed  to  any  vehicle  on  the 
virtual  battlefield.  The  Executive  Officer  was  always  tethered  to  his  ModSAF 
vehicle. 

b.  Mimic  View  -  Places  the  user  in  any  vehicle  on  the  virtual  battlefield  and 
provides  the  same  view  as  the  vehicle  commander. 

c.  Orbit  View  -  Allows  the  operator  to  remain  attached  to  any  vehicle  on  the 
virtual  battlefield  and  to  rotate  360°  about  that  vehicle,  while  still  maintaining 
the  vehicle  as  a  center  point  of  view. 

d.  Free  Fly  Mode  -  Permits  independent  3-D  movement  anywhere  in  the  virtual 
battlefield. 
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3.2.12  DIS  LAN  Network  Configuration 

A  standard  DIS  LAN  configuration  was  used  with  Ten  Base  T/AUI  cable.  Additionally,  a 
dual  port  Sun  Sparc  Station  was  configured  to  enable  the  MWTB  to  FTP  and  have  access  to 
the  Orlando  corporate  and  simulation  network. 

3.3  Database  and  Scenario  Development 

The  existing  ADST II  Fort  Hood  terrain  database  was  used  to  support  the  experiment.  The 
database  was  50  Km  by  50  Km  and  was  used  with  sunshine  and  rain  weather  conditions. 

A  series  of  four  test  scenarios  and  one  training  scenario  were  developed  to  support  FPE  III. 
Each  scenario  contained  four  vignettes  which  depicted  an  Armor  Company  conducting  a 
Deliberate  Attack,  Defense,  and  Movement  to  Contact  operations.  The  scenarios  included 
Operations  Orders  (OPORD),  Fragmentary  Orders  (FRAGOs)  and  overlays  to  support  the 
mission.  The  orders  and  overlays  were  developed  by  the  Mounted  Maneuver  Battle  Lab  and 
Lockheed  Martin  Service  Group  (LMSG)  MWTB  personnel. 


4.  Conduct  of  The  Experiment 

4.1  Troop  Training 

In  order  to  get  the  maximum  benefit  from  the  Pilot  Test,  a  two  week  period  of  time  was  set 
aside  for  troop  training  to  bring  the  soldiers  up  to  a  level  of  confidence  on  the  systems  prior 
to  the  Pilot  Test.  This  troop  training  was  conducted  at  the  MWTB  from  September  30  to 
October  11, 1996.  Subject  Matter  Expert’s  from  TRW,  MITRE  and  TARDEC  provided 
classroom  and  hands-on  training  for  Applique,  E-BCIS  and  IDS.  This  training  was 
complemented  by  MWTB  familiarization  and  orientation  on  the  actual  operation  of  the 
simulators. 

4.2  Pilot  Test 

The  Pilot  Test  was  conducted  at  the  MWTB  from  October  15-18,  1996.  During  this  week, 
the  soldiers  used  the  skills  acquired  in  troop  training  to  conduct  tactical  operations  in  a 
scenario  specially  designed  to  stress  the  systems  and  the  soldier’s  skills.  During  this  time 
special  attention  was  given  to  technical  anomalies  that  appeared.  The  anomalies  that 
appeared  during  the  Pilot  Test  involved  the  PLGR,  Applique,  and  IDS. 

The  PLGR  anomaly  involved  the  update  rate  with  Applique  and  an  occasional  hang-up  of  the 
system.  This  was  solved  by  modifying  the  start  up  sequence,  which  required  that  the  PLGR 
be  started  followed  by  a  start-up  of  Applique,  and  then  a  restart  of  the  PLGR.  In  addition,  the 
PLGR  automatic  reset  frequency  was  reduced  from  600  to  120  seconds.  These  fixes  allowed 
for  better  synchronization  between  the  two  systems  which  in  turn  provided  for  more  accurate 
updates. 

The  Applique  had  an  anomaly  during  the  Pilot  Test  which  would  cause  an  occasional  crash 
when  sending  Spot  Reports.  This  problem  was  solved  when  it  was  discovered  that  Spot 
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Reports  required  a  complete  bumper  number  to  be  included  in  the  address.  Bumper  number 
addresses  were  modified  to  meet  the  requirements.  This  corrected  the  problem. 

IDS  was  successful  in  defending  vehicles  during  the  Pilot  Test.  However,  several  issues 
arose  about  the  IDS  defensive  parameters  such  as  the  angle  of  defense,  the  percent  of 
effectiveness,  and  the  confusion  involved  when  one’s  own  vehicle  weapons  fire  was  detected. 
The  recording  of  one’s  ovm  vehicle  weapons  fire  was  removed,  and  missile  detection  was  set 
for  360  degrees  with  time  being  allotted  for  the  slew  of  the  turret.  Additionally,  an  off-line 
meeting  was  held  to  discuss  the  capabilities  of  the  system  for  those  who  needed  to  become 
more  familiar  with  the  system.  It  was  also  noted  during  the  Pilot  Test  that  the  computers 
running  the  IDS  tones  were  not  operating  at  optimum  efficiency.  This  problem  was  traced  to 
electrical  interference  within  the  building  and  a  modification  was  made  to  the  ground  strap 
between  the  computers  to  correct  the  problem. 

Following  the  Pilot  Test,  a  week  was  set  aside  to  fix  discrepancies  and  conduct  a  TRR  to 
discuss  the  problems,  solutions,  and  status  of  the  system.  The  TRR  was  held  on  October  24, 
from  which  LMC  obtained  permission  to  proceed  with  the  experiment.  Issues  from  the  TRR 
are  in  Appendix  A. 

4,3  Experiment  and  Trial  Runs 

The  trial  runs  for  the  experiment  began  October  28  and  ended  December  5,  1996.  A  total  of 
96  runs  were  conducted.  The  experimental  unit  was  a  Tank  Company  and  a  Scout  Section. 
Manned  entities  were  one  Platoon  with  three-man  crews  in  Ml  A2  simulators  configured  as 
Ml  Als.  The  remainder  of  the  Company  was  provided  by  ModSAF.  An  additional  officer 
was  provided  by  the  troops  supporting  the  experiment  to  play  the  role  of  the  Company 
Commander  and  adjacent  commanders  to  add  realism.  A  Test  Director  was  provided  by 
TECO  to  support  the  trials.  Trials  were  executed  running  the  four  scenarios  with  their  four 
vignettes.  One  scenario  with  four  vignettes  consisted  of  one  trial  day,  and  each  of  the  four 
vignettes  were  considered  a  trail  run.  The  system  configuration  was  altered  in  a  random  order 
to  detect  the  incremental  contribution  of  each  system.  The  configurations  for  the  experiment 
were  (Baseline,  Applique,  Applique/E-BCIS,  and  Applique/E-BCIS/IDS).  Table  2  defines 
the  system  configuration  and  scenario  used  in  each  trial. 
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Day/Trial 

Configuration 

Weather 

Scenario 

1/1-4 

Baseline 

I 

Sunshine 

#2 

2/5-8 

Baseline  +  Applique  +  E-BCIS  +  IDS 

Sunshine 

#1 

3/9-12 

Baseline  +  Applique  +  E-BCIS 

Rain 

#2 

4/13-16 

Baseline 

Sunshine 

#4 

5/17-20 

Baseline  +  Applique  +  E-BCIS 

Rain 

#1 

6/21-24 

Baseline  +  Applique  +  E-BCIS  +  IDS 

Sunshine 

#2 

7/25-28 

Baseline  +  Applique 

Rain 

#1 

8/29-32 

Baseline 

Sunshine 

#1 

9/33-36 

Baseline  -t-  Applique  +  E-BCIS 

Sunshine 

#4 

10/37-40 

Baseline  +  Applique  +  E-BCIS  +  IDS 

Rain 

#1 

11/41-44 

Baseline  +  Applique 

Sunshine 

#2 

12/45-48 

Baseline 

Sunshine 

#3 

13/49-52 

Baseline  +  Applique  +  E-BCIS 

Sunshine 

#1 

14/53-56 

Baseline 

Rain 

#2 

15/57-60 

Baseline  +  Applique 

Sunshine 

#1 

16/61-64 

Baseline  +  Applique  +  E-BCIS  +  IDS 

Sunshine 

#3 

17/65-68 

Baseline  +  Applique  +  E-BCIS 

Sunshine 

#2 

18/69-72 

Baseline  +  Applique  +  E-BCIS  +  IDS 

Sunshine 

#4 

19/73-76 

Baseline  +  Applique 

Sunshine 

#3 

20/77-80 

Baseline 

Rain 

#1 

21/81-84 

Baseline  +  Applique 

Sunshine 

#4 

22/85-88 

Baseline  +  Applique  +  E-BCIS  +  IDS 

Rain 

#2 

23/89-92 

Baseline  +  Applique  +  E-BCIS 

Sunshine 

#3 

24/93-96 

Baseline  +  Applique 

Rain 

#2 

Table  2  Experiment  Matrix 
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Week  One  was  October  28  to  November  1 .  Twenty  trial  runs  in  accordance  with  the  matrix 
at  Table  2  were  programmed.  Twenty  trials  were  run  and  validated  by  the  Test  Director. 

One  run  was  aborted  after  approximately  five  minutes  when  a  simulator  fell  off  the  DIS  net. 
However,  on-site  technicians  did  a  reboot  of  the  system  and  the  exercise  continued  without 
any  further  incidents.  All  subcomponents  of  the  system  (E-BCIS,  PLGR,  IDS,  IDS  Tones, 
Applique,  ModSAF,  TIM/INC,  and  Applique  LAN  Interface)  remained  operational  with  no 
anomalies.  There  were  no  major  issues  during  this  week. 

Week  Two  was  originally  scheduled  for  November  4-8  with  twenty  trial  runs  programmed. 
However,  the  week  was  reduced  to  November  4-7  with  sixteen  runs  programmed  due  to  a 
Fort  Knox  Training  Holiday  on  November  8.  Of  the  sixteen  programmed  runs,  all  were 
made  and  validated  by  the  Test  Director.  On  November  5,  trouble  developed  with  one  of  the 
TIM  computers.  This  caused  a  delay  in  the  start  of  the  second  run  of  the  day  to  replace  a  bad 
hard  drive.  Engineers  on-site  corrected  the  problem,  and  the  four  projected  runs  were 
completed  for  the  day.  On  November  6  and  7,  an  occasional  communications  loss  developed 
but  was  not  deemed  harmful  to  the  experiment.  Data  on  the  communication  loss  was 
captured  and  forwarded  to  MITRE  for  analysis.  Additionally,  on  November  7,  one  simulator 
lost  communications  with  the  network  at  the  end  of  the  exercise.  This,  however,  and  had  no 
impact  on  the  run.  Totals  at  the  end  of  Week  Two  were  36  runs  programmed,  completed,  and 
validated  out  of  the  96  required  for  completion  of  the  experiment. 

Week  Three  was  November  12-15.  This  was  Video  Week  and  VIP  Week,  with  November  14 
set  aside  as  VIP  Day.  During  VIP  Day,  a  separate  hands-on  demonstration  was  provided  to 
allow  the  customers  and  their  chain  of  command  to  experience  complete  operations  of  all  the 
subcomponents  of  the  system.  This  demonstration  had  no  impact  on  the  schedule  for  the 
week.  Additionally,  one  day  was  used  during  the  week  to  verify  a  fix  to  a  technical  issue  that 
involved  the  start  up  sequence  of  the  propagation  capability  of  the  TIM/INC.  This 
verification  was  completed  in  parallel  with  the  running  of  the  scenarios,  and  was  transparent 
to  the  exercise.  It  had  no  impact  on  the  schedule.  Sixteen  trial  runs  were  scheduled  and  run 
during  the  week.  All  sixteen  trial  runs  were  validated  by  the  Test  Director.  Cumulative 
totals  for  the  experiment  were  52  trial  runs  programmed  with  52  trial  runs  completed  and 
validated  by  the  Test  Director.  All  subcomponents  of  the  system  were  operational. 

Week  Four  was  November  1 8-22  with  twenty  trial  runs  programmed.  Twenty-one  trial  runs 
were  completed,  and  the  programmed  twenty  trial  runs  were  validated  by  the  Test  Director. 
The  twenty-first,  or  extra,  run  was  required  on  November  22  due  to  network  problems  in  the 
MWTB.  The  network  froze  during  one  of  the  runs  and  the  Test  Director  was  not  satisfied 
with  the  data  received,  therefore,  an  additional  run  was  completed  and  validated.  This  extra 
run  had  no  impact  on  the  schedule.  Cumulative  totals  for  the  experiment  were  72  trial  runs 
programmed  with  72  trial  runs  completed  and  validated  by  the  Test  Director.  All  of  the 
subcomponents  of  the  system  were  operational  for  the  week  except  for  the  incident  when  the 
network  froze. 

Open  Week  was  25-27  November  (Thanksgiving  Week)  with  no  trial  runs  originally 
scheduled.  However,  a  makeup  day  was  held  on  November  25  to  make  up  the  four  trials  not 
completed  due  to  the  training  holiday  during  Week  Two  (November  8).  Additional  trial  runs 
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were  made  on  November  26  to  get  ahead  in  the  trial  matrix.  For  this  week,  a  total  of  eight 
trial  runs  were  completed  and  validated  by  the  Test  Director.  Cumulative  totals  for  the 
experiment  were  80  trial  runs  programmed  with  80  trial  nms  completed  and  validated  by  the 
Test  Director.  All  of  the  subcomponents  of  the  system  were  operational  for  the  week. 

Week  Five  was  December  2-6  was  the  last  scheduled  week  in  the  96  Trial  Run  Matrix. 
Twenty  trial  runs  were  originally  programmed.  Since  November  26  was  used  as  a  day  to  get 
ahead  in  the  matrix,  this  was  changed  to  a  total  of  sixteen  trial  runs.  All  sixteen  runs  were 
completed  and  validated  by  the  Test  Director.  Cumulative  totals  for  the  experiment  indicated 
that  all  96  trial  runs  programmed  were  completed  and  validated  by  the  Test  Director. 

Week  Six  was  9-13  December  and  scheduled  as  a  make-up  week  to  accommodate  for  any 
maintenance  issues  or  verification  issues  that  may  have  come  up  during  the  Trial  Matrix  runs. 
This  week  was  not  needed  to  complete  the  matrix.  However,  two  days  of  excursion  runs  (E- 
BCIS  Only)  were  allocated  to  PM  Combat  ID  for  the  E-BCIS  model.,  and  three  days  were 
used  to  support  demonstrations  for  MMBL  and  TARDEC  on  the  IDS  system..  These  runs 
had  no  impact  on  the  data  analysis  obtained  from  the  ninety-six  runs  in  the  original  matrix. 

Analysis  of  the  experiment  data  was  conducted  by  TECO.  TECO  provided  an  officer  and 
noncommissioned  officer  as  the  Test  Director.  The  Test  Director  was  present  throughout  the 
experiment  and  validated  the  trial  runs  on  a  daily  basis.  Data  was  collected  on  every  run  per 
the  requirements  in  the  Data  Collection  Plan  established  by  the  MMBL  and  TECO.  This  data 
was  screened  daily  by  MWTB  personnel  and  then  turned  over  to  TECO  for  further  analysis. 

5.  Observations  and  Lessons  Learned 

5.1  Mini-FAS 

-  Observation  #1 

The  C2TD  Mini-FAS  was  conducted  in  accordance  with  the  Government’s  compressed 
timeline  constraint.  Therefore,  the  Mini-FAS  Government  and  Contractor  Evaluation  Team 
could  only  provide  true  and  accurate  findings  and  recommendations  with  a  90%  confidence 
level. 


-  Discussion  #1 

Due  to  the  sensitivity  of  the  proposed  experiment  execution  timeline,  the  Government  only 
allocated  one  calendar  month  (June)  for  execution.  The  original  goal  of  the  Mini-FAS  was  to 
accurately  analyze  several  C2TD  alternatives  and  provide  a  recommendation  to  the  customers 
on  the  feasibility  and  the  most  value-added  C2TD  system  for  the  experiment.  In  addition,  the 
team  had  an  implied  task  to  gather  information  on  the  major  simulation  systems  required  to 
be  integrated  in  the  experiment  as  outlined  in  the  Government’s  SOW.  Since  the  Applique 
system  was  the  customers’  preference,  the  Mini-FAS  was  contractually  structured  so  that  the 
first  C2TD  system  analyzed  and  evaluated  was  the  Applique  alternative.  If  the  Applique 
system  was  deemed  feasible  to  a  certain  level  of  confidence  by  all  team  members,  the  Mini- 
FAS  SOW  requirements  were  written  with  a  severable  clause  that  would  allow  the  Mini-FAS 
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to  cease  a  detailed  evaluation  of  the  other  candidate  C2TD  systems.  In  order  to  meet 
schedule,  all  Mini-FAS  trips  were  conducted  back-to-back.  Additionally,  the  Mini-FAS 
Report  was  produced  in  parallel  with  the  proposal  revision  that  was  later  submitted  as  a 
contract  modification.  The  team  brought  laptop  computers  on  their  site  visits  with  the  intent 
of  daily  accomplishing  a  complete  end-of-day  capture  of  data,  analysis,  integration  issues, 
and  tasks.  Due  to  the  compressed  time  schedule,  the  technical  complexity  of  the  proposed 
simulation  systems  to  be  integrated  in  the  experiment,  and  the  collective  experience  level  of 
the  team  members,  they  conducted  a  less  than  optimum  analysis.  For  example,  a  somewhat 
inaccurate  initial  analysis  of  the  hardware  requirements  later  resulted  in  an  identified  need  for 
additional  PCMCIA  cards  and  special  drivers  that  were  not  available  from  SCO  or  the 
Compaq  manufacturers. 

The  team  discovered  that  we  did  not  accurately  estimate  the  integration  effort  for  the  PLGR. 
Once  again,  due  to  time  constraints,  the  team  experienced  severe  difficulty  juggling  the 
parallel  tasks,  such  as  analyzing  the  information  obtain  during  the  many  visits  to  the 
Government  and  Contractor  sites,  accurately  documenting  the  facts  in  a  Mini-FAS  Report, 
preparing  and  presenting  a  decision  brief  to  the  customers,  and  revising  and  staffing  a 
contract  modification  proposal.  Although  the  end  report  was  fairly  accurate,  the  compressed 
time  caused  some  loss  or  misunderstandings  of  some  data  which  was  not  documented 
completely  until  the  end. 

-  Lesson  Learned  #1 

Prepare  and  develop  a  detailed  execution  plan  for  the  conduct  of  a  Mini-FAS,  regardless  of 
the  amount  of  time  allocated  for  execution.  Obviously  there  is  a  direct  correlation  between 
the  length  of  time  to  execute  and  the  quality  of  the  Mini-FAS  produced.  Although  the  IPT 
process  was  implemented  for  this  program,  at  times  it  was  not  completely  accurate  and 
timely  in  its  application  and  execution.  For  example,  we  did  not  prepare  and  develop  a 
detailed  execution  plan  for  the  entire  Mini-FAS  development  process.  The  plan  should 
incorporate  the  following:  (1)  analyze  the  perceived  requirements  prior  to  the  Mini-FAS,  (2) 
analyze  and  document  as  you  progress  through  the  Mini-FAS,  and  (3)  analyze  and 
consolidate  results  prior  to  submission  of  the  report.  Although  this  was  a  Mini-Feasibility 
Analysis  Study,  there  was  not  sufficient  time  to  document  and  do  as  an  accurate  of  analysis 
as  was  necessary. 

5.2  Development  and  Integration 

-  Observation  #1 

SCO  UNIX  was  difficult  to  integrate  into  the  Compaq  5150  computers. 

-  Discussion  #1 

The  installation  of  the  operating  systems  was  more  difficult  than  originally  analyzed  and 
planned.  The  installation  of  SCO  UNIX  is  a  time  consuming  process  that  involves  the 
installation  of  fifty-nine  floppy  disc  on  the  system.  This  can  be  reduced  with  the  use  of  a 
CD-ROM  and  docking  station.  At  the  start  of  the  program,  plans  were  to  use  the  docking 
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station.  However,  due  to  a  lack  of  parts  from  the  vendor,  the  CD-ROM,  driver,  and  docking 
station  were  not  available  until  after  integration  started.  We  were  forced  to  use  a  lengthy 
process  which  at  first  consumed  approximately  six  hours  per  computer.  Additionally, 
documentation  from  SCO  and  Compaq  were  not  in  complete  agreement  on  compatibility. 
Compaq  had  modified  their  hardware  after  initial  documentation  was  produced.  This 
modification  resulted  in  the  unforeseen  need  for  an  additional  third-party  driver  for  the 
PCMCIA  cards.  Through  extensive  coordination  with  Compaq  and  several  software  houses, 
the  drivers  were  obtained,  but  this  was  an  unanticipated  expense.  This  entire  process  caused 
readjustment  and  compression  of  some  integration  tasks  which  subsequently  impacted  on  the 
integration  timeline. 

-  Lesson  Learned  #1 

During  the  Mini-FAS  it  was  noted  that  a  previous  line  of  Compaq  computers  had  been 
discontinued  and  replaced  with  newer  models.  Be  very  careful  when  making  routine 
assumptions,  and  if  at  all  possible,  revalidate  them  more  than  once  prior  to  execution. 

During  our  Mini-FAS,  we  made  a  routine  assumption  in  regards  to  integrating  Compaq 
computers.  We  assumed  that  a  replacement  equipment  model  of  the  same  brand-name  line 
would  work  as  effectively  and  efficiently  as  its  previous  model  did  for  the  same  applications. 
Additional  coordination  is  required  in  the  development  of  the  Bill  of  Materials  to  ensure  that 
vendor  documentation  on  system  compatibility  between  systems  is  up-to-date  with  the  actual 
items  being  produced.  Coordinate  with  the  Government  to  allow  a  contingency  in  the  Bill  of 
Materials  to  accommodate  for  unknown  hardware  requirements.  Allow  enough  time  during  a 
Mini-FAS  and  integration  schedule  to  accomplish  the  tasks,  and  avoid  planning  according  to 
schedule  requirements. 

-  Observation  #2 

Inadequate  personnel  assets  were  originally  programmed  for  integration  at  the  MWTB. 

-  Discussion  #2 

Due  to  customer  cost  constraints,  personnel  assets  were  reduced  and  all  overtime  was  taken 
out  of  the  MWTB  integration  portion  of  the  proposal  during  negotiations.  As  projected,  we 
experienced  some  internal  (i.e.,  complexity  of  integration)  and  external  (i.e.,  late  arrival  of 
GFE)  problems  which  significantly  increased  the  original  budgeted  and  allocated  hours  of 
MWTB  support.  During  the  requirements  definition  phase  we  conducted  detailed 
coordination  discussions  to  attempt  to  prevent  a  majority  of  these  routine  problems  from 
arising.  However,  additional  MWTB  personnel  were  required  during  the  initial  set-up, 
additional  fix  phase,  and  the  troop  training  phase  of  the  experiment.  Additionally,  there  is  a 
requirement  for  supervision  of  OSF  personnel  by  MWTB  personnel  while  on-site  due  to 
security  requirements  at  the  MWTB.  This  security  requirement  causes  an  additional  burden 
on  MWTB  personnel  since  they  must  be  present  during  the  entire  integration  process. 
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The  Integrated  Product  Team  (IPT)  process  failed  to  adequately  define  the  complexity  of 
some  integration  tasks  required  at  the  MWTB  and  justify  the  hours  identified  and  allocated  in 
the  original  proposal.  Subsequently,  these  hours  were  deleted.  The  IPT  process  should  have 
anticipated  some  additional  integration  problems  and  supported  the  additional  hours  with  a 
detailed  justification.  To  further  complicate  this;  the  overall  technical  complexity  of 
integrating  all  the  major  systems  required  a  detailed  Systems  Engineering  Integration  Plan 
which  we  did  not  produce.  We  assigned  individual  tasks  to  specific  individuals  and  did  not 
give  enough  attention  to  parallel  efforts.  We  were  focused  too  much  on  ever  changing  GFE 
arrival  dates  and  not  task  analysis  or  completion.  The  timely  arrival  of  operational  GFE  could 
have  made  the  integration  much  easier.  Additionally,  provisions  should  be  made  by  the 
EMC  Program  Management  Office  to  clear  specific  OSF  personnel  for  off-hour  access  to  the 
MWTB  to  allow  more  flexibility. 

-  Observation  #3 

CVSD  Boards  were  extremely  difficult  to  integrate  into  the  FPE  III  simulators  and  we  lacked 
a  complete  pre-integration  test  facility. 

-  Discussion  #3 

MITRE  designed  the  boards  and  Modem  Technologies  produced  the  boards  and  associated 
wiring  interfaces.  Modem  Technologies  did  not  provide  any  updated  documentation  to 
MITRE.  We  discovered  during  the  early  stages  of  integration  that  the  documentation  from 
MITRE  was  old  and  not  complete.  Lack  of  close  coordination,  on-hand  test  tool  equipment, 
and  the  transfer  of  documentation  between  MITRE  and  Modem  Technologies  prevented  the 
CVSD  boards  from  being  properly  tested  at  either  location.  All  of  these  issues  resulted  in  an 
extensive  search  for  adequate  documentation  and  an  extended  amount  of  time  required  to 
ensure  that  the  CVSD  boards  were  operational  and  could  interface  with  the  manned 
simulators.  Due  to  the  above  problems  encountered,  we  exceeded  the  original  hours 
proposed  and  budgeted  to  execute  this  task. 

-  Lesson  Learned  #3 

When  multiple  vendors  are  responsible  for  the  design  and  production  of  a  product,  the 
agency  responsible  for  integration  must  have  a  complete  understanding  of  the  roles  and 
responsibilities  that  each  vendor  has  in  the  design  and  production  process.  The  integrator 
must  ensure  a  complete  documentation  package  is  provided  and,  if  possible,  develop  a  one- 
stop  integration  testing  facility. 

-  Observation  #4 

Failure  to  receive  IDS  tones  and  voice  files  in  the  correct  format  and  numerous  slips  in  the 
delivery  date  of  the  system  increased  the  amount  of  support  required  to  integrate  this  system. 
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There  was  some  initial  confusion  between  LMC,  TARDEC,  and  Optimetrics  on  the 
requirements  associated  with  this  task,  specifically  on  the  exact  format  and  content  of  the 
digitized  voice  files.  This  problem  was  further  compounded  with  the  late  arrival  of  the  IDS 
software,  corrupted  files,  and  the  need  to  modify  IDS  Tones  software  several  times  after  its 
original  submission.  Optimetrics  did  not  have  significant  experience  in  the  DIS  protocol 
arena,  therefore  there  was  a  flaw  in  the  initial  design  of  the  IDS  model.  We  eventually  froze 
the  software  code  and  installed  the  system,  but  then  discovered  an  additional  problem  with 
the  electrical  noise  and  interference.  This  noise  was  difficult  to  isolate,  and  was  not 
completely  corrected  until  a  ground  strap  was  developed  and  installed  after  the  Test 
Readiness  Review. 

-  Lesson  Learned  #4 

This  issue  relates  to  the  lack  of  an  adequate  plan  to  start  the  Mini-FAS  which  would  have 
made  the  understanding  of  the  tones  requirement  more  clear  and  better  understood  by  all 
agencies  involved.  Additionally,  further  analysis,  including  consideration  of  ground  strap 
loop  potentials  and  the  use  of  shielded  cables,  should  have  been  conducted  during  the  Mini- 
FAS. 


-  Observation  #5 

The  Functional  Test  Plan  was  adequate  but  not  in  as  much  detail  as  it  should  have  been.  The 
plan  was  not  required  in  the  Government  SOW,  and  never  discussed  in  the  IPT  process. 

-Discussion  #5 

The  Functional  Test  Plan  was  developed  by  a  quick  analysis  of  the  basic  requirements  from 
the  GFE  subcomponents  paragraphs  in  the  Statement  of  Work.  On  the  surface  this  seemed  to 
be  adequate.  However,  a  more  detailed  analysis  of  the  entire  Statement  of  Work  for  all 
requirements  and  a  better  coordination  effort  with  the  GFE  vendors  on  the  capabilities  of  the 
specific  models  could  have  provided  more  insight  to  GFE  capabilities  and  requirements. 

GFE  suppliers  should  have  been  involved  with  LMC  in  the  development  of  the  Functional 
Test  Plan.  This  would  have  resulted  in  a  more  detailed  plan,  and  a  more  stressful  Functional 
Test.  As  a  result,  more  issues  would  have  been  captured  in  the  Functional  Test  and  fewer 
issues  would  have  come  up  during  the  Pilot  Test. 

-  Lesson  Learned  #5 

Developing  a  Function  Test  Plan  should  be  a  specific  task  outlined  in  the  proposal  and 
allocated  an  appropriate  amount  of  hours  to  perform.  Additionally,  it  should  be  highlighted 
and  aimotated  on  the  integration  schedule  and  tracked  as  a  separate  task.  The  development 
of  the  plan  should  be  a  joint  (Government  and  contractor)  effort  with  the  prime  integration 
contractor  taking  the  lead.  Additionally,  more  time  needs  to  be  devoted  by  the  contractor  and 
GFE  suppliers  to  analyze  system  requirements.  GFE  model  suppliers  should  also  be  familiar 
with  their  model  requirements  and  assist  in  development  of  the  plan. 
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-  Observation  #6 

The  Test  Readiness  Review  agenda  should  have  been  revised  to  incorporate  more  technical 
discussion  on  behalf  of  the  customers. 

-  Discussion  #6 

The  Test  Readiness  Review  was  designed  as  a  decision  brief  based  on  a  high  level  discussion 
of  the  systems  subcomponents,  technical  issues  and  solutions  that  came  from  integration  and 
testing.  Even  though  the  Test  Readiness  Review  was  a  successful  process,  some  confusion  as 
to  total  system  requirements  did  exist  on  behalf  of  the  test  personnel.  Additional  time  should 
have  been  allocated  to  each  of  the  GFE  suppliers  and  customers  to  verify  that  requirements 
and  capabilities  have  been  met,  and  to  provide  a  high  level  overview  of  their  product. 

-  Lesson  Learned  #6 

Design  or  structure  the  Test  Readiness  Review  so  that  system  requirements  and  customer 
needs  are  addressed  as  well  as  technical  issues,  solutions,  and  the  state  of  readiness  of  the 
system.  Identify  and  list  all  key  players  that  need  to  attend  this  review.  We  should  insist  that 
this  review  be  attended  by  both  the  customers  management,  technical  engineers,  and  each 
Government  agency’s  support  contractor. 

5.3  Experiment 

-  Observation  #1 

There  was  not  a  complete  understanding  of  all  the  requirements  and  objectives  of  the 
experiment  by  test  personnel,  contractor  personnel,  and  the  customers. 

-  Discussion  #1 

The  experiment  ran  extremely  smooth  and  on-schedule,  and  an  excellent  rapport  was 
established  between  the  customer,  contractor,  and  test  personnel.  However,  there  were  times 
when  clear  and  complete  understanding  of  all  the  requirements,  priorities,  and  capabilities 
for  each  subcomponent  of  FPE  III  was  lacking.  We  discovered  during  a  discussion  on 
propagation  during  week  three  (3)  that  the  personnel  who  developed  the  test  plan  did  not 
have  a  copy  of  the  Government  Statement  of  Work,  and  that  the  contractor  and  all  the 
customers  did  not  have  a  copy  of  the  TECO/MMBL  Test  Plan.  The  test  plan  was  developed 
from  requirements  in  the  Battle  Lab  Experiment  Plan  (BLEP),  revised  and  dated  August  15, 
1996,  after  the  proposal  and  ECP  were  submitted.  Even  though  the  Statement  of  Work  and 
the  Battle  Lab  Experiment  Plan  (BLEP)  have  a  lot  of  common  language,  all  players  must  be 
provided  with  all  revisions  to  documentation  on  a  consistent  basis,  and  be  involved  in  the 
planning  or  staffing  of  essential  documents  and  requirements. 

-  Lesson  Learned  #1 

It  is  vital  that  the  Government  agency  who  heads  the  experiment  data  collection  and  analysis 
properly  invites  all  the  key  Government  and  contractor  personnel  to  each  internal  meeting  to 
disseminate  the  most  accurate  and  up-to-date  requirements  and  documentation.  The 
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Government  should  ensure  that  all  documentation  is  provided  to  all  participants  in  the 
experiment  and  all  key  participants  should  be  involved  in  the  staffing  of  all  critical 
documents  such  as  the  test  plan.  Additionally,  all  of  the  participants  should  be  involved  in  all 
of  the  planning  meetings  (i.e..  Data  Collection  Meetings,  In  Process  Reviews  and  Training 
Meetings) 

5.4  Overall 

-  Observation  #1 

Coordination  and  delivery  of  GFE  items  was  more  difficult  than  anticipated. 

-  Discussion  #1 

As  a  general  rule,  the  arrival  of  GFE  was  late,  it  arrived  in  various  states  of  operational 
condition,  and  documentation  was  not  accurate  or  non-existent.  This  caused  unnecessary 
delays  and  the  shifting  of  integration  tasks  in  the  OSF.  Ultimately,  it  deferred  some 
integration  tasks  to  the  MWTB. 

-  Lesson  Learned  #1 

Although  flexibility  is  key  in  ADST II,  better  coordination  needs  to  take  place  during  the 
entire  life  of  a  program  .  GFE  items  must  be  clearly  defined,  delivery  dates  need  to  be 
adhered  to,  and  a  complete  understanding  must  be  reached  with  all  players  as  to  the  exact 
nature  of  the  GFE  delivered  item.  The  focus  of  the  Technical  Interchange  Meetings  (TIMs) 
seemed  to  be  more  oriented  on  EMC  efforts,  and  GFE  development  status  was  always  an 
add-on.  It  is  recommended  that  in  the  future,  all  GFE  developers/suppliers  take  a  lead  role  in 
TIMs  and  be  responsible  for  presentations  on  the  status  of  their  product.  Otherwise, 
STRICOM  must  either  convince  the  customer(s)  to  transfer  responsibility  and  decision 
making  authority  to  the  entire  experiment  integrator,  or  hold  the  respective  Government 
customer(s)  totally  responsible  for  adequately  coordinating  resources  from  other  Government 
agencies.  This  should  preferably  be  in  writing  prior  to  the  end  of  the  Requirements 
Definition  phase. 

-  Observation  #2 

Detailed  information  on  specifics  of  past  efforts  was  difficult  to  obtain. 

-  Discussion  #2 

It  was  difficult  to  obtain  information  and  become  educated  on  past  efforts.  After  reviewing 
past  documentation,  it  was  not  clear  who  the  current  or  past  subject  matter  experts  were. 

-  Lesson  Learned  #2 

The  configuration  management  library  contained  prior  documentation  and  information,  there 
was  not  an  obvious,  detailed,  or  all-encompassing  list  of  Government  and  contractor  SME 
POCs  for  that  Delivery  Order.  Therefore,  we  relied  entirely  on  the  memory  of  certain 
individuals  to  identify  previous  POCs  with  which  to  communicate  in  regards  to  certain 
reusable  systems  and  models.  We  recommend  that  this  Final  Report  provide  and  attach  a 
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POC  list  with  telephone  numbers.  This  list  will  allow  future  activities  to  have  a  starting  point 
in  doing  their  research. 

-  Observation  #3 

The  OSF  does  not  have  the  capability  to  read  copies  of  tapes  provided  by  off-site  agencies. 

-  Discussion  #3 

During  the  Mini-FAS  and  during  integration,  software  tapes  were  provided  to  the  program 
from  Ft  Hood,  Fort  Knox,  and  industry.  The  purpose  of  these  tapes  was  to  have  access  to 
technical  data  and  to  assist  in  integration.  In  all  cases  the  tapes  provided  could  not  be  read  by 
equipment  in  the  OSF.  This  issue  relates  to  tape  density  and  compression.  It  is  obvious  that 
OSF  equipment  is  not  compatible  with  the  equipment  of  many  outside  agencies.  The  only 
way  data  could  be  received  was  to  use  FTP.  FTP  efforts  with  large  files  takes  many  hours. 

-  Lesson  Learned  #3 

Upgrade  the  OSF  to  a  level  that  will  allow  transfer  of  data  and  computability  with  other 
agencies.  Efforts  are  underway  to  upgrade  equipment  in  the  OSF  to  read  low,  medium  and 
high  compression  tapes. 

-  Observation  #4 

Reliability  of  the  Ml  A2  simulators  at  the  MWTB  is  unsatisfactory. 

-  Discussion  #4 

It  is  a  fact  proven  with  historical  data  that  the  life  of  a  Ml  A2  simulator  is  approximately  one 
and  a  half  hours.  This  appears  to  be  a  system  limitation  and  an  accepted  way  of  doing 
business.  As  the  reliability  decreases,  problems  develop,  and  the  systems  must  go  through  a 
long  startup  sequence.  This  issue  impacts  on  scenario  development,  exercise  duration,  time 
spent  on  the  simulators  during  integration  and  testing,  and  the  length  of  the  schedule  required 
to  accomplish  the  experiment.  Even  though  the  ninety-six  trial  runs  had  minimal  problems 
during  the  actual  running  of  the  scenarios,  a  major  effort  was  required  to  start  the  simulators 
at  the  start  of  every  day  and  between  runs.  The  scenarios  were  designed  with  this  limitation 
in  mind,  and  most  exercises  ended  just  prior  to  problems  occurring.  To  prevent  problems 
from  appearing  in  the  next  run,  a  lengthy  reboot  effort  took  place  between  each  run  and  an 
excessive  amount  of  time  was  wasted  between  runs.  Excessive/wasted  time  with  troops 
sitting  around  between  runs  becomes  a  common  practice.  A  more  reliable  system  would 
decrease  the  time  to  actually  conduct  an  experiment  which  would  save  cost,  decrease  troop 
support  time,  and  improve  the  troop’s  confidence  in  the  system.  This  would  create  better 
performance  during  the  experiment.  During  the  twenty-four  days  of  trial  runs,  seventy-two 
incidents  occurred  with  the  simulators.  Simulator  reliability  status  is  at  Appendix  B. 
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-  Lesson  Learned  #4 

Resources  should  be  allocated  through  the  CDF  Upgrades  DO,  as  well  as  using  DO  cost 
savings,  to  study  and  improve  the  reliability  of  the  simulators. 

-  Observation  #5 

Time  and  effort  for  documentation  for  an  experiment  of  this  complexity  was  significantly 
more  than  proposed. 

-  Discussion  #5 

We  significantly  imder  estimated  the  elaborate  detail  and  quantity  of  documentation  that  has 
to  either  be  revised,  modified,  or  newly  developed  for  configuration  management  purposes. 
The  Cold  Start  Manual  and  Version  Description  Documents  were  perceived  as  minimal 
effort.  The  technical  complexity  of  the  experiment  was  enormous  considering  all  the 
hardware  and  software  components  that  were  integrated.  The  Cold  Start  Manual  will  be 
lengthy  ,  the  Version  Description  Document  has  numerous  separate  sections  (ModSAF, 
PLGR,  IDS  Tones,  and  Applique  Interface)  totaling  approximately  seventy  pages.  The 
Final  Report  and  Hardware  Design  and  Configuration  Document  (HDCD)  will  be  very 
detailed  and  newly  prepared.  The  Government  has  a  requirement  for  the  HDCD  to  be  very 
complex,  with  each  subcomponent  to  be  separately  drawn  down  to  the  cable  level. 
Additionally,  we  are  providing  an  Interface  Control  Document  which  is  not  required  but 
necessary  due  to  the  complexity  of  the  experiment.  Furthermore,  at  the  time  of  proposal 
submission,  the  internal  process  for  templates  and  procedures  was  not  established.  The 
established  procedures  now  are  more  detailed  than  anticipated. 

-  Lesson  Learned  #5 

This  problem  appears  to  be  well  along  the  way  to  being  solved.  LMC  Program  Management 
and  STRICOM  efforts  have  established  formats  and  examples  of  the  above  mentioned 
documents  in  template  format.  This  now  allows  the  engineers  to  write  an  initial  version  of 
the  documents  through  out  the  program,  which  would  then  only  requires  updates  as  you 
finish  of  the  program.  Additionally,  a  better  understanding  of  the  documentation 
requirements  in  the  Requirement  Definition  phase  by  the  engineering  staff,  management 
staff  and  the  customer(s)  would  greatly  reduce  the  time  associated  with  this  task. 

6.  Conclusion 

The  Force  Protection  Experiment  III  (FPE  III)  was  a  fast  paced  and  technically  complex 
effort  that  achieved  its  goal.  The  successful  integration  of  multiple  GFE  software  models 
into  the  MWTB  hardware  provided  the  desired  synthetic  environment  for  the  customers. 

This  environment  allowed  them  to  analyze  and  evaluate  the  resulting  data  to  assist  in 
developing  better  force  protection,  increased  survivability,  and  enhanced  command  and 
control  procedures.  Combined,  these  enhancements  will  better  preserve  the  force  in  combat 
operations. 
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The  experiment  also  provided  valuable  information  to  TRW,  MITRE  and  PM  Applique 
on  the  performance  and  integration  of  Applique,  the  CVSD  Boards,  and  the  TIM/INC,  as 
well  as  insight  into  issues  for  Force  XXL 
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7.  Points  of  Contact 

ADST II FPE  III  Team 

E.G.  Fish 

Project  Director 

407-306-4456 

G.W.J.  Kenney,  Jr 

Systems  Engineer 

407-306-4376 

Kevin  Mueller 

ModSAF,  SW  Lead 

407-306-4455 

Mike  Blocker 

Hardware  Engineer 

407-306-4225 

James  Page  III 

ModSAF  mods 

407-306-1900 

James  McCulley 

Linux  &  SCO  Unix 

407-306-4613 

Cristl  Weckenmann 

S/W-TIM/INC/PLGR 

407-306-5637 

Bob  Meyer 

PLGR,  SW  mods 

407-306-4139 

Don  Appier 

MWTB  Site  Manager 

502-942-1092 

Eberhard  Kieslich 

MWTB  Lead  Engineer 

502-942-1092 

Paul  Monday 

MWTB  Data  Collection 

502-942-1092 

Dan  Schultz 

MWTB  Battlemaster 

502-942-1092 

Charles  West 

MWTB  Asst  Battlemaster 

502-942-1092 

Don  DeBord 

MWTB  Asst  Battlemaster 

502-942-1092 

Tim  Voss 

MWTB  SW  Technican 

502-942-1092 

Rob  Smith 

MWTB  Engr  Technican 

502-942-1092 

Paul  Monday 

MWTB  SW  Integration 

502-942-1092 

Ron  Flackler 

MWTB  Image  Generator 

502-942-1092 

Tom  Van  Lear 

MWTB  Technican 

502-942-1092 

STRICOM 

Major  Chris  Bailey 

Project  Director 

407-384-3671 

Chris  Metevier 

Project  Engineer 

407-384-3865 

Customer  Points  of  Contact 

Joe  Jarboe 

MMBL,FtKnox 

502-624-8451 

Ron  Kacsmar 

PM  Combat  ID 

908-427-2234 

Ed  Maluszczak 

E-BCIS  Proj  Lead,  Ft.  Monmouth 

908-427-5270 

Stephanie  Habedank 

PM  Combat  ID 

908-427-5038 

Bryan  Beaudoin 

TARDEC 

810-574-6693 

TRW  (Applique  Software) 

Joe  Provenzano 

TRW,  Deputy  PM 

310-764-3510 

Mr.  George  Gallagher 

APM  Training,  ILS  for  TRW 

310-764-3054 

Comnaa  (Appliaue  Hardware) 

Jess  Long 

SCO  and  Model  5150  SME 

713-927-1276 

Tech  Support 

800-652-6672 
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Creative  Labs  (Sound  Blaster  Cards) 


Advanced  Users 

405-742-6600,  x  6655 

Pwilliams@creaf.com 

405-742-2327 

PM  Annliaue  Ft.  Monmouth 

LTC  Van  Fossen 

Program  Manager 

908-427-2966 

JoJo  Clemente 

SW  Engineer 

908-427-3121 

David  Egli 

Computer  Scientist 

908-427-2718 

Paul  Lucyk 

Technical  Management 

908-427-2786 

Frank  Nissen 

Technical  Management 

908-427-2780 

CECOM  Ft.  Monmouth 

Bill  Sudnikovich 

Ft.  Monmouth,  NJ 

908-427-4093 

MITRE  New  Jersey 

Ed  McCarthy 

MITRE 

908-389-5685 

Jon  McConnell 

MITRE  TIM/INC-PM 

908-389-5670 

Jeffery  Vogel 

MITRE  TIM/INC-SW 

908-389-5670 

Mark  Riehl 

MITRE  TIM/INC-SW 

908-389-6752 

Gus  Diaz 

MITRE  TIM/INC-Sys  Engr 

908-389-5670 

Jerry  Michael 

MITRE-Sys  Engr 

908-389-6743 

LvnnSoft,  Inc..  305  Mountain  Drive  Suite  E,  Destin  FL  32541  (SCO  Drivers') 

Brenda  Follis 

Sales 

904-650-2266 

MrOtt 

Manager 

904-650-2266 

Ouatech.  Akron.  Ohio  -  DSP-100. 

tDual  Channel  RS  232  PCMCIA)  216-434-3154 

Kevin  Kline 

Lead  Engineer 

800-553-1170 

330-434-3154 

SAIC  San  Dieso  (V2  Annliaue  Hardware) 

Rollie  Brubaker 

619-552-5481 

SCO 

Craig  Lockwood 

Sales 

408-439-4158 

800-386-2172 

Paul  Herford 

Sales 

408-427-7583 

Dave  Rankin 

SCO  Restin  VA  -  SAIC 

703-715-8734 
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OTHER  PERSONNEL 

Jorge  Cadiz,  GDLS 

ADST  I,  EXFOR  Applique 

DO  Manager 

470-380-5500 

Robert  Fraser,  Illusion 

ADST  I,  EXFOR 

407-359-1232 

Ft.  Hood 

Training  Site,  EXFOR 

817-287-5282 

817-288-4098 

Steve  Gilbertson,  TRADOC 

BCIS 

804-728-5863 

MAJ  Kirkpatrick,  TECO  Ft  Knox 

Test  Director 

502-624-2710 

Ken  Mellin,  PM  Cbt  ID 

E-BCIS 

703-578-3765 

Dr  Parrish,  White  Sands 

EXFOR  Janus 

505-678-4949 

Shin  Shey,  MIT  Lincoln  Labs 

Constructive  Modeling 

617-981-0705 

CPT  Joe  Taylor,  Ft  Knox 

Hit  Avoidance 

502-624-2453 

Rich  Mezan,  AMSAA 

Validation  &  Verification 

410-278-2091 

MITRE,  Bedford.  Mass 

Ron  Williams 

E-BCIS  Lead  Engineer 

617-271-3939 

Stan  Manoski 

E-BCIS  Engineer 

908-389-6772 

Chris  Nissen 

E-BCIS  Engineer 

617-271-3370 

Jeffrey  Blanchard 

E-BCIS  Engineer 

617-271-7138 

Beth  Gallivan 

E-BCIS  SW  Engineer 

617-271-5457 

Mark  Riehl 

E-BCIS  SW  Engineer 

908-544-8863 

OMI,  Ann  Arbor,  MI 

Fred  Smith 

Vice  President 

313-973-1249 

William  Miller 

Vice  President 

313-973-1177 

Allan  Dunston 

IDS  SW  Engineer 

313-973-1249 

Approved  for  public  release;  distribution  is  unlimited 


26 


ADST-II-CDRL-1 8R-9600423 
January  29, 1997 


Acronym  List 


AAR 

After  Action  Review 

ADST 

Advanced  Distributed  Simulation  Technology 

BCIS 

Battlefield  Combat  Identification  System 

BFV 

Bradley  Fighting  Vehicle 

BLEP 

Battle  Lab  Experiment  Plan 

BLUFOR 

Blue  Forces 

C2 

Command  and  Control 

C2TD 

Command  and  Control  Tactical  Display 

CDF 

Core  DIS  Facility 

CDRL 

Contract  Data  Requirements  List 

CECOM 

Communications  &  Electronics  Command 

CIG 

Computer  Image  Generator 

CVSD 

Continuous  Variable  Slope  Delta 

DDL 

Digital  Data  Link 

DO 

Delivery  Order 

DIS 

Distributed  Interactive  Simulation 

E-BCIS 

Enhanced  Battlefield  Combat  Identification  System 

EPLRS 

Enhanced  Position  Location  Reporting  System 

EXFOR 

Experimental  Force 

FPE  III 

Force  Protection  Experiment  III 

FRAGO 

Fragmentary  Order 

FTP 

File  Transfer  Protocol 

GFE 

Government  Furnished  Equipment 

GPS 

Global  Positioning  System 

HDCD 

Hardware  Design  Configuration  and  Document 

H/W 

Hardware 
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IDS 

INC 

I/O 

LAN 

LMC 

LMSG 

LRF 

MIAx 

MBT 

Mini-FAS 

ModSAF 

MMBL 

MMW 

MWTB 

OC 

OPFOR 

OPORD 

OMI 

OS 

OSF 

PC 

PDU 

PLGR 

PM 

POC 

PPP 

PVD 

RAM 

RIU 


Integrated  Defense  System 
Internet  Controller 
Input/Output 
Local  Area  Network 
Lockheed  Martin  Corporation 
Lockheed  Martin  Service  Group 
Laser  Range  Finder 

Abrams  Main  Battle  Tank  (“x”  =  variant) 

Main  Battle  Tank 

Mini  Feasibility  Analysis  Study 

Modular  Semi- Automated  Forces 

Mounted  Maneuver  Battle  Lab 

Millimeter- W  ave 

Mounted  Warfare  Test  Bed 

Observer  Controller 

Opposing  Forces 

Operations  Order 

Optimetrics,  Inc 

Operating  System 

Operational  Support  Facility 

Personnel  Computer 

Protocol  Data  Unit 

Precision  Lightweight  GPS  Receiver 

Program  Manager 

Point  of  Contact 

Point-To-Point  Protocol 

Plan  View  Display 

Random  Access  Memory 

Radio  Interface  Unit 
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RP 

Role  Player 

SAP 

Semi-Automated  Forces 

SCO 

Santa  Cruz  Operating  System 

SEIT 

Systems  Engineering  Integration  Team 

SGI 

Silicon  Graphics  Industries 

SIMNET 

Simulation  Network 

SINCGARS 

Single  Channel  Ground  and  Airborne  Radio  System 

SME 

Subject  Matter  Expert 

SOW 

Statement  of  Work 

SRE 

SINCGARS  Radio  Emulator 

SRM 

SINCGARS  Radio  Model 

STRICOM 

(US  Army)  Simulation  Training  and  Instrumentation  Command 

TACOM 

Tank  Automotive  and  Armaments  Command 

TARDEC 

Tank  Automotive  and  Armaments  Command  Research  Development 
and  Engineering  Center 

TC 

Tank  Commander 

TECO 

Test  and  Evaluation  Coordination  Office 

TF 

Task  Force 

TIM 

Tactical  Internet  Model 

TIM 

Technical  Interchange  Meeting 

TRR 

Test  Readiness  Review 

TTP 

Tactics,  Techniques,  and  Procedures 

UDP 

User  Data  Protocol 

VDD 

Version  Description  Document 

VMF 

Variable  Message  Format 

VIP 

Very  Important  Person 
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Appendix  A  -  Test  Readiness  Review  Issues 

The  Test  Readiness  Review  was  held  at  the  MWTB  on  October  24, 1996  with  all  the 
customers  present  as  well  as  representation  from  OPTEC,  AMSAA,  MITRE,  Optimetrics, 
and  PM  Applique.  The  following  issues  were  discussed  by  subsystem: 

1.  E-BCIS:  The  E-BCIS  model  was  reported  as  operational.  Discussion  took  place  with 
regard  to  the  degraded  laser  range  finder  using  three  inches  of  rain  per  hour  in  the  model. 

The  discussion  did  not  question  the  validity  of  the  model,  but  was  of  the  nature  to  bring  the 
audience  up  to  date  on  the  parameters.  The  effect  of  the  degraded  laser  condition  was  that  a 
“Friend  in  Sector”  indication  would  be  given  when  normally  a  “Friend”  indication  would 
occur,  since  there  would  be  no  laser  range  to  compare  to  the  BCIS  mmW  range  (BCIS  could 
not  verify  that  the  targeted  vehicle  was  indeed  the  “Friend”  responding).  There  was  no  effect 
on  the  fire  control  system  with  this  modification.  Additionally,  discussion  took  place  on 
capabilities  of  E-BCIS,  and  it  was  noted  that  not  all  of  the  players  were  aware  that  the  E- 
BCIS  had  a  minimum  range  of  1 50  meters. 

2.  PLGR:  The  PLGR  model  was  reported  as  operational,  and  discussions  took  place  on  the 
fixes  to  the  start  up  sequence,  reset  time,  and  synchronization  with  Applique  that  had  taken 
place  over  the  preceding  week.  It  was  noted  that  the  PLGR  had  a  lengthy  startup  process  that 
impacted  time  available  during  the  day  for  running  the  experiment.  With  knowledge  of 
position  reporting  being  timely  and  accurate  through  the  Applique  LAN  Interface,  it  was 
agreed  by  all  the  customers  to  replace  the  PLGR  with  the  Applique  LAN  Interface  position 
reporting  capability.  This  seemed  to  be  the  logical  approach  since  it  was  projected  to  save 
over  an  hour  a  day  and  allocate  more  time  for  actual  experiment  runs. 

3.  IDS:  The  IDS  model  was  reported  as  operational.  Discussion  took  place  on  the  following 
issues:  that  reporting  of  own  main  gun  fire  had  been  removed;  that  missile  defense  was  now 
set  for  360  degrees;  and  that  there  was  a  need  to  have  a  follow  up  session  on  IDS  capabilities 
to  educate  the  participants  on  the  system.  Additional  discussion  took  place  on  IDS  tones, 
which  remained  an  open  issue.  This  issue  was  closed  on  the  first  day  of  the  experiment  when 
a  modification  to  the  ground  strap  was  installed  on  the  tones  computer  to  reduce  facility 
electrical  interference.  This  allowed  the  computers  to  run  in  an  optimum  state. 

4.  Applique:  The  Applique  model  was  reported  as  operational.  However,  discussion  did 
take  place  on  the  Applique  screen  update  rate  and  the  fact  that  it  could  be  changed  from  20 
seconds  to  10  seconds.  It  was  decided  at  the  TRR  to  leave  the  update  rate  at  20  seconds  since 
the  troops  had  already  trained  on  the  system  and  that  there  might  be  an  impact  on  data 
collection.  Applique  data  storage  requirements,  and  Applique  Interface  timing.  Trackball 
sensitivity  was  discussed,  and  was  an  open  item  at  the  end  of  the  TRR.  A  change  to  the 
trackball  sensitivity  was  made,  approved  by  the  customer,  and  installed  on  the  first  day  of  the 
experiment. 

5.  ModSAF:  ModSAF  was  reported  as  operational.  No  issues  were  discussed.  However,  it 
was  noted  that  a  list  of  nonstandard  ModSAF  parameters  were  required  for  documentation. 

6.  TIM/INC:  These  models  were  reported  as  operational  and  no  issues  were  discussed. 
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7.  Applique  Interface:  It  was  noted  that  the  Applique  Interface  would  replace  the  PLGR  on 
position  reporting  and  that  the  interface  was  supposed  to  supply  OPFOR  position  reports  to 
Applique  from  the  IDS. 
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Appendix  B  -  M1A2  Simulator  Reliability  Issues 

The  Force  Protection  Experiment  III  was  conducted  over  a  period  of  twenty  four-days  (days 
of  actual  exercise  runs).  During  this  twenty-four  day  period,  the  Battlemaster  and  staff  at  the 
MWTB  experienced  seventy-two  problems  with  the  on-site  simulators. 

Simulator  Equipment  Issues  are: 

- 15  incidents  of  host  computer  lock  up 

-  21  incidents  of  sound  reset  due  to  the  loss  of  host  aural  cues 

-  2  incidents  of  IDC  reset  where  the  simulator  IDC  board  looses  inputs 
through  the  serial  line 

-  6  incidents  where  the  host  fell  off  the  network 

-  1 1  incidents  of  call  back  error  between  the  host  and  the  IG 
- 16  graphic  error  incidents  with  the  IG 

- 1  incident  of  CIG  lockup 
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